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‘Software systems deployed in safety-critical applications in aerospace and other industries must satisfy rigorous development and verification 
standards. One ofthe most widely used of these standards is DO-178B, “Software Considerations in Airborne Systems and Equipment Certification.” 
10-1788 specifies 66 software development process objectives, distributed across various stages in the development lifecycle. it was published in 
1992, when most software was hand-coded. As a result it does not cover advanced software development technologies, and must be mapped onto 
the processes and tools in Model-Based Design, 


‘This article compares three approaches to using Simulink” system models and Model-Based Design to develop safety-critical systems that must 
satisfy the DO-1788 standard, 


Using the model to capture only low-level software requirements 
Using the model to capture both high-and lowlevel software requirements 


Using separate models to capture the high-level and lowlevel software requirements 


‘An autopilot design demonstrates a design flow that uses a single Simulink model as both the high-level and low-level software requirements. 
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Figure 1. Model as lowlevel software requirement. The leters and 
‘numbers refer to development and verification activities specified in 
100-1788. Click on image to see enlarged view. 


Using the Models to Capture Both High- and Low-Level Software Requirements 
Inthe second approach the Simulink made is considered tobe both te hghevel and lwvievel software requirements (Figure 2) 


By reducing the numberof artifacts that must be developed, this approach reduces the development and verification effort. To implement this 
approach, however, the system requirements must be suficiently detailed to enable the models tobe traced to and veriid from those requirements. 


htpswow.mathwarks.com/companyinewslaters/aticies/madel-based-design-for-do-178b html a0 


Exhibit D13, page 740 


Case 2:22-cv-09094-GW-MAR Document 454-18 Filed 04/24/23 Page 3of11 PageID 
#:7727 
4124123, BAS AM Model-Based Design for DO-178B - MATLAB & Simulink 
ae 
reagent 
Sie, | 
serene 121 oe ve mis 


Figure 2. Model as combined high-level and low-level requirements. 
The letters and numbers refer to development and verification 
activities specified in DO-178B. Click on image to see enlarged view. 


Capturing High-Level and Low-Level Software Requirements in Separate Models 


With tis approach, a Simulink model captures the high-level software requirements. Details added to the model to capture the low-level requirements 
and for code generation (Figure 3). The high-level requirements model might be continuous-time, while the low-level requirements models used for 
‘code generation might be discrete-time. 


‘The disadvantage of this approach is that two models must be maintained and verified, increasing the risk of error. The transition from the high-evel 
requirements model tothe low-level requirements madelis another potential error point 
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Figure 3. Diferent models capturing high-level and low-level 
‘requirements, The letters and numbers refer to development and 
verification activities specified in 00-1788. Click on image to see 
enlarged view. 


An Autopilot Example 


‘This example uses a single Simulink model as bath the high-level and low-level software requirements, 


‘An autopilot is typical of the kinds of aircraft system that might be designed using Simulink and Model-Based Design. in atypical workflow, the control 
systems engineer performs trade studies and analysis forthe autopilot and then provides the design to the software group to implement ina target 
system 


Because an autopilot controls the aircraft, it usually must meet the highest level of safety. As a result, itis challenging for the development team to 
‘conduct the necessary development and verification activities and to provide evidence tothe certification authorities that those activities were carried 
‘out properly and completely. 


The Design Workflow 
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‘The design workflow begins with the following steps: 


Capturing and veriying system requirements 
Designing the system 

Veriying the system design 

Allocating the system design to software 


‘The design team then completes the software steps requited by DO-1788: 


Defining and verifying software requirements 
Defining the software design and architecture 
Verifying the software design and the source code 


Generating and verifying executable object code 


Capturing and Verifying System Requirements 


“The system requirements forthe autopilot’ all as are provided ina Micrasoft Word document (Figure 4). The team implements each requirement in 
a section ofthe document that also contains the rationale forthe requirement. Using Simulink” Verification and Validation” software, they can race 
equitements directly to the design model via hyperlinks. 
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Figure 4. System requirements document. Click on image to see 
enlarged view. 


Requirements validation, which demonstrates that the requirements are complete and correct, is typically performed by reviewing a checklist of 
requirements standards forthe project. 


Modeling and simulation can assist inthe validation af the requirements. As the system design is developed, you can simulate the model to ensure 
that the requirements are complete and correct. Simulation can uncover undesirable system behavior that was not considered in the requirements. In 
some cases, it can demonstrate thatthe requirements are not verifiable. 


Designing the System 


Figure 5 shows the system design model 
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Figure 5. System design model. Click on image to see enlarged view. 


‘The layout ofthe top level ilustrates a basic system architecture that represents the system design and enables us to verify that the system design 
satisfies the system requirements 


Verifying the System Design 


‘with the system design implemented in the Simulink model, we can verify the design against the system requirements without having to implement 
that design in actual hardware and software. 


“The top level of the model includes three signal builder blacks: 


Engage and Mode Pane! 
Reference Signals 


Cockpit Controls 
‘We can use these blocks to conduct specific tests during simulation. 


f course, test stimulus alone is not enough to verify thatthe system design satisfies the requirements. We use Assertion blocks, contained in the 
subsystem Vetification_Blacks (Figure 6), to determine whether the design satisfies the system requirements during simulation. 


Figure 6. Veriication subsystem. Click on image to see enlarged 


‘The Verification subsystem includes four Assertion blocks: 
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‘check Dynamie Rall 
‘Check Roll Range 
‘Check Roll Rate Range 
‘Check aileron Range 
‘The assertions Check Roll Range, Check Roll Rate Range, and Check Allon Range provide minimum and maximum values for roll angle, rll rate and 
aileron angle respectively. These assertions are enabled during all test cases. The values, including tolerances, are based on the requirements 


document. 


“The assertion Check Dynamic Roll provides a window between minimum and maximum values that depends on the test case being executed. The 
signal builder block Roll References is used to provide the minimum and maximum values for each testcase using signal groups. 


Because we are using three signal builder blacks for test stimulation and ane for assertion control requirements, we must coordinate the selected 
signal group for each of these blocks. With SystemTest™ software we can coordinate the test cases and automate test case execution, 


‘SystemTest provides a framework for setting up test in three phases: Pre Test, Main Test and Post Test 
Pre Test 

We can use Pre Test to setup variables that are used during al iterations of Main Test 

During Pre Tes, the following sequence is run: 

Get requirements links, a MATLAB® element that gets requirements links from a signal builder block in the model 

‘Set up descriptions, a MATLAB element that provides descriptions and pass/fail criteria text for each test which is included inthe test report 
Main Test 


Main test enables us to iterate through test cases. in our example, we use the Test Vector parameter index to define the execution of the 20 test cases 
that we have defined. 


During Main Test, the following sequence is run for each iteration 
‘Run Test Harness, a Simulink element that executes the model 


Pre-Process Pass/Fail Data, a MATLAB element that computes the minimum value of each Assertion Block output lagged during the execution of 
<do178b_dhe2 in the Run Test Harness element 


Verify Pass/Fail, a Limit Check element that checks the values from the Pre-Process Pass/Fall Data element in order to report the status of the 
assertions in SystemTest 


‘Build Input Array, 2 MATLAB element that takes data logged from the inputs tothe Roll AP reference model in dot78b_dhe2 model and prepares that 
data for used in the next Simulink element 


‘Run rollap, Simulink element that runs the rell_ap model 


Pre-Process Comparison Data, a MATLAB element that computes the difference between the model reference output of rll_ap generated during Run 
‘Test Hamess and the output generated directly from the roll_ap model during Run roll_ap 


Verify Results Match, a Limit Check element that veifes that the maximum difference between the results computed in Pre-Process Comparison Data 
‘Save MAT File, MATLAB element that saves data logged from the Simulink elements to @ MAT fle for use in generating atest report during Post Test 


‘Save Excel File, a MATLAB element that saves the data logged forthe reference model rll_ap in Run Test Hamess so thatthe data can be used to 
verify the executable object code target system 


Post Test 
We can use Post Test to analyze variables that are computed during all iterations of Main Test. During Post Test the following sequence is run 


Generate Test Report, a MATLAB clement that generates atest report in POF format using the MAT file data that was stored during Main Test (Figure 
oy) 
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Figure 7. Alleron command data plot for Test 19. Click on image to 
‘see enlarged view. 
‘Run Model Advisor, a MATLAB element that runs a Model Advisor report for the model rll_ap 


Generate Requirements Report, 2 MATLAB element that generates a requirements traceability report for the system requirernents document and the 
rolLap model 


Generate Target Code, 2 MATLAB element that generates target code forthe roll_ap model 


Defining and Verifying Software Requirements 


‘Specific functions from the system design are allocated to software to form the software requirements. In our example, the Autopilot subsystem 
(Figure 8) Is allocated to software, and becomes the high-level software requirements. 


Figure 8. Autopilot architecture. Click on image to see enlarged view 


“The Autopilot subsystem architecture is further broken down into three subsystems: Roll Autopilot, Pitch Autopilot, and Yaw_Damper. The 
Roll Autopilot subsystem contains a Model Reference block, Roll AP (Figure 9) 
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Figure 9. Roll Autopilot reference madel. lick an image to see 
enlarged view. 


‘The Roll_AP function is contained in a separate model that called from the system model (Figure 10). We can look inside the roll_ap model to see 
the functionality that is allocated to software 


Figure 10, Roll Autopilot function. Click on image to see enlarged 


‘The roll_ap model architecture is broken down into two reference models, Heading Mode and Rall Reference, and one subsystem, Basic Roll Mode. 


For D0-1788, we must provide requirements verification artifacts demonstrating system requitements accuracy and consistency, veriiaility, and 
algorithm accuracy. We can use the system design verification activities described inthe previous section to partially meet these objectives. We must 
also review the model against the system requirements using a checklist or other measure 


We generated a requirements traceability report using the Simulink® Report Generator product during the Post Test phase of SystemTest, 


‘As a part of the DO-1788 lifecycle, we must very that the high- and low-level requirements comply with DO-178B standards. We must also show that 
the requirements are compatible withthe target computer. Simulink Model Advisor lets us perform statle checks on the model to verify many 
standards automatically and 10 verify certain code generator option settings related to hardware compatiblity. 


Defining the Software Design and Architecture 


‘The software design and architecture are defined within the roll_ap model and the Heading_Mode and attitude controller reference models for the 
control portion of the rol autopilot function. For this function we generate the code directly from the high-level software requirements. As a result the 
model satisfies both the high- and low-level software requirements. 


‘Additional design and architecture activities wll be required to fully define the high- and lowlevel software requirements. For example, there will be 


requirements and dasign associated with processing the inertial reference and air data sensor inputs, passing thase inputs to the model inputs, and 
scheduling these tasks in the proper order. 


Verifying the Software Design and the Source Code 


Because we have combined the high- and lowlevel software requirements, we can use the software requirements verification activities previously 
described to cover software design veifcation, 


The source code is generated from the rollap model using Real-Time Workshop” Embedded Coder”. The cade includes comments that trace each 
ling of the code back to the model and to the requirements document (Figure 11). 
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Figure 11. Source code from the rollap model. Click on image to see 
enlarged view. 


‘Source code is usually verified using code reviews. We use Polyspace™ products to perform automated verification activities on the source code. 
‘These checks detect any MISRA C compliance issues, run-time errors, unreachable code, uninitialized variables, and data coupling issues, 


‘We generate the executable object code from the source code using thiréparty compilers and links. We can generate makefiles for the software build 


‘process manually or by using Real-Time Workshop Embedded Coder. 


In the System Design Verification phase, we saved Excel” fles during simulation for use in executable object code verification. The fle shown in Figure 


‘12s atypical example of how the data might be used by a software test platform to run tests on the executable object code. This file contains data 


‘epresenting the time and the input and output data for each time step. 
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Figure 12. Excel ile generated during system design verification 
Click on image to see enlarged view. 


During equirements-based testing, we must also perform structural coverage analysis on the code to measure statement, decision and modified 
condition or decision coverage. This is one of the most expensive and time-consuming aspects of the DO-17BB objectives. 
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During the simulations run from SystemTest, a Model Coverage Report was generated automatically, thus providing a measurement of the 
effectiveness of the requirements based tests early in the development process rather than after code i tested (Figure 12). 
“The Model Coverage Tool can provide the following information: 

‘cyclomatic complexity 

Decision coverage 

Condition coverage 

Modified condition/decision coverage 

Lookup table coverage 


‘Signal range coverage 


Figure 13. Model coverage report. Model coverage isnot code 
coverage, but when proper cade generation options are selected it 
‘maps very well o code coverage under most circumstances. During 
‘execution ofthe tests on the object code using the Excel ile, tis best 
‘to use a code coverage too! to evaluate the structural coverage of the 
‘code. There are many thie-party coverage tools available for 
analyzing code coverage. Some instrument the code, in which case 
the tests must be run on instrumented and urvinstrumented versions 
of the object code. Click on image to see enlarged view. 
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‘Simulink Report Generator 
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